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family consists primarily of a small, general-purpose multi -programming 
monitor designed to control a wide variety of real-time input/output devices. 
User programs are relieved from the details of I/O timing, data buffering, 
priority handling, and task scheduling. In addition, they are provided with 
a parallel processing capability plus inter-task communication and synchro- 
nization facilities. Communication with the monitor takes place through a 
small set of meta-instructions (consisting primarily of machine -language 
subroutine calls). The system, which is entirely core -resident, is highly 
modular and largely reentrant, allowing for the straightforward addition 
of special device handlers. 
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1.1 INTRODUCTION 

family consists primarily of a small, general -purpose multi -program- 
ming monitor designed to control a wide variety of real-time input/ 
output devices. User programs are relieved from the details of I/O 
timing, data buffering, priority handling, and task scheduling. In 
addition, they are provided with a parallel processing capability plus 
inter-task communication and synchronization facilities. Communica- 
tion with the monitor takes place through a small set of meta- instruc- 
tions (consisting, primarily of machine- language subroutine calls). 
The system, which is entirely core -resident, is highly modular and 
largely reentrant, allowing for the straightforward addition of spe- 
cial device handlers. 

RTOS is designed specifically for the handling of multiple user tasks. 
These tasks are created by means of one of the meta- instructions, and 
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processing situations lend themselves admirably to this sort of opera- 
tional control philosophy. Simple examples include the reading or 
writing of a block of data while simultaneously performing some other 
(possibly unrelated) operation, listening for input from several devices 
at the same time, shared device use by multiple tasks, sophisticated 
communications problems, etc. As will be seen from the meta-instruc- 
tions available, RTOS is a small, rudimentary time-sharing system. Its 
parallel processing capability is, however, discussed here more as a 
means for writing control programs for a wide variety of I/O devices 
rather than as a way to run several computations in parallel, although 
the latter feature is clearly a part of the system. 
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1.2 RTOS TASK STATES 

As a "TASK" is the basic logical unit which is controlled by RTOS, it 
is necessary at this time to describe the concept of a TASK, and 
define some of its operational states during existence. Essentially, 
a TASK is a logically complete program segment, operating at a speci- 
fied priority level, whose execution may proceed simultaneously with, 
and independently of other TASKs (although communication and synchro- 
nization between TASKs is permitted and provided for in RTOS) . Due to 
the serial nature of the computer, TASKs which appear to execute in 
parallel are in actuality executed in short (serial) segments. It is 
necessary, then for RTOS to maintain certain status information (pri- 
marily active registers) concerning all TASKs which are not currently 
in a state of execution. This information is retained within an in- 
formation structure called the "TASK control block" (TCB) , which is a 
seven word block of storage structured as follows: 
USAGE WORD 



RTOS LINKAGE WORD 







CARRY + PRIORITY 




1 


AC0 STORAGE 




2 


AC1 STORAGE 




3 


AC2 STORAGE 




4 


AC3 STORAGE 




5 


PC STORAGE 




6 


Figure 1-1 


TCB 


FORMAT 



The maximum number of TASKs which may be supported in any RTOS con- 
figuration is defined at RTOS assembly time (by specifying a value for 
the "JOBS" parameter). At any given time, each of these TASKs will 
exist in one of four states which are described in the following 
sections. 

1.2.1 EXECUTING STATE 

A TASK is executing when the central processing unit (CPU) has been 
restored to the state specified in the TASK'S TCB. Note that when a 
TASK is in the executing state, it has control of the CPU and no TCB 
is required. 
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A TASK is pending when it is ready and available for execution. A 
TASK becomes pending if and only if: 

a) it is being initiated for the first time (with the .FORK 
command) , 
or b) an RTOS meta- instruction is executed and a TASK of equal or 

hieher orioritv is nending. 
or c) a teletype break occurs (see description of the .BRK 

command) , 
ot \xj tiie rea_L-tun6 operation it was awaiting lias occured/been 
completed. 

1.2.3 SUSPENDED STATE 

A TASK is suspended whenever it must await the occurrence or completion 
of some real-time operation. More specifically, this condition may 
exist if and only if: 

a) an I/O operation (.IOX) has been initiated by the TASK and 
it is not yet complete, 
or b) the TASK has given a .RCV request and is awaiting a corre- 
sponding .XMIT fron another TASK, 
or c) the TASK has given a .XMIT request with the "@" option and 

is awaiting the corresponding .RCV from another TASK, 
or d) the TASK has given a .WAIT request and is awaiting the 

passing of the specified number of clock cycles, 
or e) the TASK has given a .BRK request and is awaiting the occur- 
rence of the specified break character on a teletype. 

1.2.4 DORMANT STATE 

A TASK is dormant if it is neither suspended, pending, or executing. 
This situation exists if and only if: 

a) the TASK has not yet been created in the system (with the 
. FORK command) , 



1-3 



or b) the TASK has been terminated, either due to the execution 
of a .QUIT command or the break character being received 
or a .RCV being issued on a previously .RCV activated channel. 

The various modes of transition between the four TASK states in RTOS are 
illustrated in Figure 1-2. 




Figure 1-2 TASK STATE TRANSITION 



1.3 



RTOS META- INSTRUCT IONS 



Communication between user TASKs and RTOS is effected by means of eight 
"meta- instructions". These met a- instruct ions, mostly subroutine calls, 
are declared as entry points (.ENT) to RTOS (which is supplied as a re- 
locatable package, and thus must be declared as externals (.EXTN) to 
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the user program. Alternatively, an absolute binary tape of RTOS 
could be prepared for special situations, in which case the meta- 
instructions would be user -defined as transfers through the appro- 
priate address vector on page zero. 

It should be noted that all meta- instructions return control by 
means of the RTOS TASK scheduler, which will place the current TASK 
in the pending state if any TASKs of equal or higher priority are 
pending when the meta- instruction is executed. In addition, the TASK 
scheduler is activated whenever a TASK is transferred from the sus- 
pended to the pending state (i.e. - when a real-time operation has 
been completed). This technique is employed, rather than using the 
real-time clock to generate "time slices", in an attempt to reduce 
overhead in the system as well as provide some user control over the 
scheduling operation (which is desireable in a control environment) . 
A true, "time- slicing" mode of operation is available to the RTOS 
user, however, and will be discussed under the description of the .WAIT 
instruction. 

1.3.1 .IPX INSTRUCTION 

.IOX 

<logical device #> 
<device control word> 
<first data item pointer> 
<data item count> 
<error routine address> 
<normal return> 

This is the standard I/O operation in RTOS, initiating an activity on 
the specified device. If the device is currently busy (i.e., servicing 
an . IOX request from another TASK) , execution of the requested opera- 
tion will be postponed until the device becomes free. Once this execu- 
tion begins, absolute control of the device is guaranteed to the TASK 
until the .IOX operation has terminated. In all cases, the execution 
of an .IOX causes the current TASK to be placed in the suspended state, 
making a transition to the pending state only when the requested func- 
tion has terminated. Note that this may effectively be avoided, if 
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desired, by the logical structure created by the following command 

sequence : 

P-. FORK ; create parallel process 
.IOX ; perform I/O operation 
.QUIT ; terminate TASK when I/O complete 
► — ; parallel process to avoid hang-up 

The use of parallel processes (i.e., multi-TASK's) allows a TASK to 
communicate with a given device without having to concern itself with 
whatever other task may be using it. For example, a number of TASKs 
could "simultaneously" be reading some control variable through an 
A/D converter input. Needless to say, multiple TASKs generating out- 
put on "serial" devices such as the paper tape punch must take care 
to include identifying information within the output data block. 

The device type on which the I/O operation will be performed is in- 
dicated by the "logical device number", the first parameter of the 
.IOX command. Logical device numbers for each class of devices (e.g., 
= teletype, 1 = high speed paper tape reader, 3 = line printer) are 
specified in the individual device handler descriptions which are in- 
cluded in an appendix to this manual. It should be noted that device 
handlers may be capable of servicing multiple units of the same device 
type. In these cases, the specific unit is indicated by a device unit 
number which forms part of the device control word. The teletype is 
an example of a device whose handler can service multiple units. 

The second parameter of the .IOX command is called the device control 
word and is used to specify all device -dependent options. In this 
section, the teletype device control word will be shown for illustra- 
tive purposes; other device control words are specifically described 
in the appendix on Peripheral Support. 

An attempt has been made to keep these device control words as compat- 
ible as possible, so much of what is given regarding the teletype will 
hold true for other devices as well. The teletype device control word 
is shown in Figure 1-3. 
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1 2 3 4 5 6 7 8 9 1)0 11 12 13 14 IS 



Device Unit Number 



-* UNUSED 

-♦ASCII Parity Bits 

-»0 = ASCII Mode, 1 = IMAGE Mode 

-»-0 = Character Format, 1 = Word Format 

-»• = Echo on Input, I = Suppress Echo 

-*• = Input , 1 = Output 



Figure 1-3 Teletype Device Control Word Format 

The next two parameters of the .IOX command give the starting address 
of the data list and the data item count. These two parameters are 
either a byte pointer/byte count or a word pointer /word count depending 
on the format specified in the device control word. 

The last .IOX parameter is the address of an error program. If an error 
occurs during the processing of an .IOX meta-instruction, the error 
return address parameter is used as the return PC when the TASK is 
placed in the pending state. 

1.3.2 .FORK INSTRUCTION 

.FORK 

<new task priority> 

<new task address> 

<return> 

The .FORK meta-instruction is the basic mechanism for the creation of 
parallel processes (i.e., multiple TASKs) in RTOS. Its execution causes 
the creation of a new TASK (with its associated TCB) at a specified 
priority level. Priorities in the range l-255-,0 may be used (255]fl 
being the lowest priority) ; specifying a level of causes the new TASK 
to be created with the same priority as the executing TASK. Both TASKs 
are placed in the pending state when the .FORK is executed, and the 
system scheduler determines which TASK will next be placed in the exe- 
cuting state. From this point onward, the two TASKs exist as separate 
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entities in the system; no structure or hierarchy is remembered. 
Much of the power of RTOS is inherent in the .FORK mechanism. 

Note that if both the executing TASK and the new TASK created by the 
.FORK are of the same priority (new task priority = in .FORK call) 
the previously executing TASK will be re-scheduled before the new 
one. This convention allows for the convenient initiation of I/O 
activities without suspending the corresponding computation (as il- 
lustrated in the . IOX description) . 

1.3.3 .QUIT INSTRUCTION 

.QUIT 
This meta- instruction is used to terminate the execution of the cur- 
rent (executing) TASK. The TASK is placed in the dormant state and 
will not become pending unless re-created by a .FORK command. .QUIT 
is implemented simply as an entry to the TASK scheduler, preserving 
none of the current TASK information. 

1.3.4 . PTY INSTRUCTION 

.PTY 

<new priority level> 

<return> 

The .PTY meta- instruction is used to dynamically alter the priority of 

the current executing TASK. Priorities within the range 0-255ig are 

permitted, being specified by the eight least significant bits of the 

new priority level parameter. Level 255-^ (377 8 ) is the lowest priority. 

Note that level 0, the highest RTOS priority level, may only be speci- 
fied by a .PTY command (i.e., not by a .FORK operation). A number of 
special system operations take place at this level and the user should 
exercise discretion regarding attempts to run TASKs at this priority. 
System integrity will be maintained but any "compute -bound" operation 
at level zero will cause a serious degradation in I/O operating speeds. 
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1.3.5 .WAIT INSTRUCTION 

.WAIT 

<# of clock cycles > 

<return> 

This meta- instruction is used to delay the execution of the current 

TASK for a specified time interval. The executing TASK is placed 

in the suspended state for the indicated number of clock cycles, 

TCll 1 m*71 T\CT "wVli r"ll it 1C "h-ron C-FoT»V*Or1 i~n -f-Kcn T>£*nrl-i -nrr c-f- n-t-a T.rV»-i /-»V» moV^c* 

-»- '-'-■--4.'-' •»-*-**.£, Ilil4-^il J, *^ J.*^ l,X LU1^)J.V1 J. WV*. ^^ U1V UViiUXllt J I^UL^ j WJ1XV11 JllC4.XV%_-0 

it available for scheduling. Specifying a zero or a negative number 
of clock cycles as the waiting time causes the current TASK to be 
immediately placed in the pending state, allowing the scheduling of 
any other TASKs of the same priority. This feature is provided as a 
convenient technique to force rescheduling. 

The duration of a system clock cycle is set at 10 milliseconds in the 
distributed version of RTOS. Other frequencies are available (See 
the appendix on System Generation) and may be in use at a given sys- 
tem installation since it appears on the parameter tape. 

It should be noted that the real-time clock interrupt routine which 
is used by RTOS does not directly call the scheduler (although it may 
do so indirectly by virtue of the fact that a TASK which has been sus- 
pended due to a .WAIT operation will cause rescheduling when it be- 
comes active again) . This means that if a number of "compute-bound" 
TASKs are active at the same priority level, the current one will 
remain running unless it executes a meta- instruction or a higher pri J 
ority TASK forces rescheduling. This potentially undesireable (in 
some cases) situation would be avoided in a true "time-slicing" en- 
vironment, which may be created by having a time slice clock task 
which performs the following instruction sequence: 

.PTY ;Priority set to highest or could be 

<0> ;set to one immediately below which 

.WAIT ; time- sharing is to take place 

<n> ;The time slice duration 
JMP .-2 
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The implementation of the time slice RTOS system assures that a compute 
bound task will not lock out the activities of other tasks of the same 
priority. The number of real time clock interrupts (n) that must occur 
before the scheduler is entered is set by the user. Care must be 
exercised when choosing this time slice interval because it affects 
the system overhead. 



1.3.6 .XMIT INSTRUCTION 

.XMIT .XMIT 

<channel #> or <@ channel #> 
<return> <return> 

This is the first of a pair of complementary meta- instructions which 

are provided for the purposes of TASK synchronization and inter-TASK 

communication. The synchronization is performed through a number of 

transmit/receive "channels", the available number being defined at 

RTOS assembly time (nominally eight in the distributed system, with 

zero being the first channel number) . 

The .XMIT command causes transmission of a "synchronization signal" 
over the specified channel. If an "@" sign is present in the channel 
number argument, the TASK will be placed in the suspended state until 
the .RCV signal has been received. Otherwise, the TASK will be al- 
lowed to continue. In either case, the contents of AC0 at the time 
of the .XMIT request are retained by RTOS as a single word "message" 
to the receiving TASK (this "message" could, of course, be the address 
of a more lengthy message stored somewhere in core memory) . 

It is intended that there be a one to one correspondence between .XMIT 
and .RCV requests. An .XMIT to an illegal channel number functions as 
a .QUIT. Second and subsequent .XMIT operations on the same channel 
(before the corresponding .RCV is executed) act as no-operations, a 
feature which may be used to ascertain first occurrences of specific 
conditions, critical timing situations, etc. 
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1.3.7 .RCV INSTRUCTION 



.RCV 

< channel #> 

<return> 



This meta- instruction forms the second half of the synchronization/ 
communication facility in RTOS. The .RCV command enables the recep- 
tion of a "synchronization signal" sent by a .XMIT over the specified 
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the suspended state until the signal is received, at which time it 
will be made pending and become available for execution again. Need- 
less to say, if the signal (sent by .XMIT) had already been trans- 
mitted (and was therefore awaiting reception) , the TASK issuing the 
.RCV would not enter the suspended state, but would be immediately 
available for scheduling. In all cases, when the TASK resumes execu- 
tion AC3 will contain a copy of the "message" sent by the correspon- 
ding .XMIT operation. 

Specifying either a negative or an illegal channel number in the .RCV 
request will be handled like a .QUIT. Second and following requests 
to a channel activated by a previous .RCV command will also cause a 
.QUIT operation. 

It should be clear that the .XMIT/. RCV meta- instruction pair may be 
used for both inter-task communication (via the "message" word) and 
synchronization purposes. Note that a "join" operation as shown in 
Figure 1-4, logically complementing the .FORK instruction, is imple- 
mented simply by the use of a .XMIT/. RCV pair, the .XMIT being 
followed by a .QUIT. . 

• FORK- 



.XMIT 

<NN> 
.QUIT 



, .RCV 

L - - _ _ <NN> 



1 



Figure 1-4 Inter-TASK Communication 
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1.3.8 . BRK INSTRUCTION 

.BRK 

<character code (ASCII) > 

<return> 

The .BRK meta-instruction is a special -purpose command which allows 
the input of a specified ASCII character to interrupt the normal oper- 
ation of RTOS tasks. Any number of teletypes or teletype-like devices 
in the system may be connected to this facility. It is an assembly 
time parameter with the last word of the DUCB being set negative if 
the break feature is disabled and set equal to the teletype unit number 
if the break is enabled. 

The TASK issuing the .BRK request is placed in the suspended state until 
the specified break character is typed on one of the enabled teletypes. 
At this time, any operation on this teletype will be terminated, suspended 
TASKs awaiting I/O on this teletype will be made dormant, the break TASK 
will be returned to the pending state, and the scheduler will be called. 
When the break TASK begins executing, AC3 will contain the unit number of 
the teletype which initiated the break request. 

Additional .BRK requests, result in the previous .BRK request being 
terminated and an error message being sent back to the user in AC3. Its 
value is dependent on the value of the new break character. Possible 
values for AC3 are as follows: 

AC3 -1 Break request terminated by another legal request 
AC3 -2 Break request terminated by a new .BRK request with 
a negative break character. 

The new .BRK request may also return back to the user TASK with AC3 set to 
-3. This indicates that the break character in the call was negative. 

Note that the .BRK instruction is not intended to function as a general- 
purpose meta-command. Its use is primarily intended for and should be 
restricted to, the operation of a keyboard-oriented executive, or monitor 
TASK running at the user level. 
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CHAPTER 2 

RTOS IMPLEMENTATION DETAILS 

The primary function of RTOS is the supervisory control of four 
basic operations: TASK state transition, TASK synchronization/com- 
munication, real-time clock servicing, and input/output device 
servicing. Each of these areas of interest will be discussed 
separately. 

2.1 TASK STATE TRANSITI ON 

2.1.1 EXECUTING TASK 

An executing TASK, by definition, has control of the central proces- 
sing unit (CPU) . The only parameter which RTOS must necessarily re- 
tain concerning such a TASK is its current priority. The variable 
location '.CPTY' always contains the priority of the current executing 
TASK. 

When a TjSK in RTOS is in the executing state, the CPU is said to be 
in USER MODE. Otherwise (i.e., RTOS is engaged in some system function 
such as TASK scheduling), the CPU is said to be in SYSTEM MODE. Due 
to the random nature of interrupts in a real-time environment, plus the 
desireability of reducing interrupt latency as much as possible, it 
was not feasible to make all system functions in RTOS fully reentrant. 
Instead, a variable location ('.SYS.') is used as a switch to denote 
USER MODE ('.SYS.' = 0) or SYSTEM MODE ('.SYS.' f 0) . This technique 
protects against illegal reentrancy while still allowing for optimal 
priority scheduling. 

2.1.2 PENDING TASK 

Two queue structures are maintained to facilitate the manipulation of 
TASKs in the pending state. Of primary concern is the "pending TCB 
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queue", which is maintained by the TASK scheduler. TCBs contained in 
this queue are linked in order of decreasing priority (i.e., increasing 
numerical value). Location '.QUE.' contains the address of the first 
TCB in the chain, which "points" to the next in turn, and so on to the 
end of the queue. The final TCB entry has a zero pointer value to 
mark the end of the chain. The pending TCB queue, then, is structured 
as follows: 
.QUE.: 







PENDING TCB's 

The nature of a real-time environment dictates that suspended TASKs may 
become active at any time. Unfortunately, the routine to enter a TCB 
into the pending TCB queue cannot be reentrant, as correct chaining 
must be assumed at all times. Therefore, the (non- reentrant) TASK 
scheduler is given the unique right to insert TCBs into this queue. 
TCBs which dynamically become pending are reentrantly pushed into a 
special stack ('.JSTK') maintained for this purpose (this stack is 
pointed to by '.JPNT'). Each time the scheduler is called, it checks 
to see if any new TASKs have become pending (i.e., are in '.JSTK'). 
If so, the associated TCBs are entered into the pending TCB queue prior 
to raising to the executing state the highest priority pending TASK. 

2.1.3 SUSPENDED TASK 

Pointers to the TCBs for suspended TASKs are maintained within the 
various routines in RTOS which service real-time operations (i.e., 
routines handling the operations which caused the TASKs to become sus- 
pended) . More detailed descriptions of these specific structures are 
covered elsewhere in this document. 
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the associated TCB is pushed into '..JSTK. * stack. Subsequently, this 
TCB will be entered into the pending TCB queue the next time the 
scheduler is called, and will be executed according to its relative 
priority. 






A dormant task is by definition unknown to RTOS, and therefore no 
information need be maintained concerning it. The .QUIT me ta- instruc- 
tion, which causes an executing TASK to become dormant, is me-ralv a 
call to the system scheduler. 

2.1.5 NULL TASK 

When the RTOS TASK scheduler determines that the pending TASK queue 
is empty, it initiates a null TASK. This TASK is started by clearing 
location zero and the carry bit, restoring the system to USER MODE, 
and jumping to location zero. The null TASK will continue executing 
a "JMP 0" in location until a hardware interrupt causes a user TASK 
to be made pending as described above. When the computer is in the 
null TASK only the RUN, ION, and FETCH lights of the console will be 
lighted. 

2.2 INTER-TASK COMMUNICATION 

Two tables of length 'CHAN' are maintained by RTOS to handle .XMIT/.RCV 
inter-TASK communication. 'CHAN, is equal to the number of available 
.XMIT/.RCV channels and is set by the user at system generation. 

The first is the channel status table ('.CST.'), containing one entry 
per channel. This entry is in one of four different formats: 

-- zero entry indicates channel in- 
active 
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ADDR 



1 






-- indicates that a .RCV has been re- 
quested on the channel. 'ADDR' is 
the TCB address of the associated 
suspended .RCV TASK. 

-- indicates that a .XMIT has been 
sent to the channel with no sus- 
pension of the TASK 

-- indicates that a .XMIT has been sent 
to the channel, and the TASK is 
awaiting a corresponding .RCV re- 
quest. 'ADDR' is the TCB address 
of the suspended .XMIT TASK. 

The second is the channel message table ('CMT'), also containing one 
entry per channel. When a .XMIT is initiated on a given channel, the 
16-bit synchronization message (i.e., the contents of AC0 at the time 
of the .XMIT) is stored in the relevant channel entry in the message 
table 'CMT 1 . 



ADDR 



3 



2.3 



REAL-TIME CLOCK SERVICING 



The real-time clock supplied with the Nova family of computers is capa- 
ble of being operated at four different frequencies, one of which is 
selected as the standard RTOS clock time. This is done at RTOS assembly 
time, by specifying an appropriate value for 'FREQ' ; it may also be 
accomplished during system run-time by modifying the 'FREQ' entry in 
the device control block for the real-time clock - '.CUCB+3.'. Each 
"tick" of the clock is used to decrement an appropriate count down in- 
terval value, which, when its value reaches zero, allows the suspended 
TASK to be made pending. 

In order to handle multiple simultaneous .WAIT requests, a "clock count 
down interval queue", '.CLK.', is maintained, structured in a similar 
fashion to the pending TCB queue. Each queue entry contains three 
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words, defined as follows: 



FWD LINK 


CDI 


ADDR 



link to next queue entry (final entry = 0) 
count down interval (# of clock ticks) 
address of suspended TCB 



Location '.RTC in the clock service routine contains the address of 
the first entry in the interval queue, thereby creating the following 
structure: 



.RTC. : 



LINK 



"I f 



1 

LINK 


-> 


LINK 




~ i 
LINK 


+ $; + 


i 




CDIi 


CDI 2 


CDIi 


CDI n 


TCB-l 


TCB 2 


TCB. 

i 


TCBnO 



Each count down interval value is, in reality, an incremental count 
down value. In other words, the total elapsed time before the sus- 
pended TASK represented by TCB i is made pending is given by x clock 
"ticks", where, 

x = CDI, + CDI 9 + CDI, + + CDI. 

1 l 3 i 

The routine to handle the clock count down interval queue, much as in 
the case of the pending TCB queue routine, can not be reentrant, as 
the queue requires protection from multiple simultaneous accesses. 
However, the real-time clock must be allowed to run continuously as 
long as the interval queue is not empty in order to prevent error accu- 
mulation in multiple- interval timing situations. In order to alleviate 
these problems, an "overcount" state has been provided in the clock 
service routine, operating as follows: should RTOS (i.e., the .WAIT 
service routine) be accessing the queue when the interrupt service 
routine also desires access, the overcount state is entered and the 
clock continues to run. When the interval queue again becomes available, 
additional counts are provided according to the number of overcount 
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cycles which occurred thereby maintaining accuracy with minimal 
processing overhead. 

2.4 INPUT/OUTPUT SERVICING 

All user I/O is accomplished by a request to RTOS using the .IOX 
command. The .IOX section of RTOS is responsible for allocating 
the use of all standard devices of the system. It provides for ref- 
erencing all I/O devices by logical unit numbers instead of physical 
unit numbers. The assignment of the logical unit numbers is made 
at system generation time (see Appendix A) . 

Each I/O device on the system has a handler associated with it. 
Control is transferred to the handler from the .IOX processor. If 
the required device is already busy, the request is stacked for later 
execution. If the device is not busy, the device is activated to 
input or output the first character or word. The task requesting the 
I/O operation is suspended until the transmission is completed. 

If the request is illegal for some reason (e.g., illegal logical unit 
number, negative word count, etc.), control is returned to the user 
program at the error return address. 

Device handlers with two exceptions (real-time clock and teletype), are 
written as separate, relocatable subroutines which are linked to RTOS 
at load time by the relocatable loader. The two exceptions are made 
for the following reasons: 

a) the real-time clock is not treated as a standard peripheral 
(it communicates with .WAIT rather than .IOX) and is not 
an optional device. 

b) the teletype is assumed to be present in most systems and 
its handler is general-purpose and flexible enough to pro- 
vide major services for almost all other device handlers. 

Each I/O handler performs operations and functions on a specific device 
only. This means that a handler must be provided for each hardware 
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device in the computer system. Handlers have been written and are 
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reader and punch, the incremental XY plotter, and the analog to 
digital converter, Handlers for the card reader, line printer, fixed 
head disk, magnetic tape, data communications system, and other de- 
vices interfaced to the Nova computer will be made available as they 
are developed. 
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CHAPTER 3 
DEVICE HANDLER IMPLEMENTATION 

3.1 .IPX INSTRUCTION 

The .IOX meta- instruction of RTOS provides the linkage between user 
TASKs and the individual device handlers. The calling sequence has 
been briefly described in section 1.3.1. 

3.1.1 LOGICAL DEVICE NUMBER 

The device type on which the I/O operation will be performed is in- 
dicated in the first parameter of the .IOX calling sequence and 
referred to as the logical device number. Logical device numbers 
for each class of device on the system have been arbitrarily assigned 
in the released version of RTOS as follows: 

Teletype keyboard and printer 

1 High Speed paper tape reader 

2 High Speed paper tape punch 

3 Line printer 

4 Incremental plotter 

5 Card reader 

6 Fixed head disk 

7 Analog to digital converter 

8 Magnetic tape 

9 Data communications multiplexer 

The assignment of logical device numbers may be changed at system 
generation time by the user modifying the order of the table of de- 
vice handler addresses starting at location 'HANTB'. 

If the logical device number is outside the above range (negative or 
greater than 9-jn) or it specifies a device that has net been declared 
as part of the hardware configuration at system generation time, an 
illegal device number error will occur. The error return will be made 
with AC3 = 0. 
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3.1.2 DEVICE CONTROL WORD 

The device control word format will be discussed bit by bit in this 
section. This control word is used to specify all the device- 
dependent options to the device handler. In this description, the 
teletype device control word will be used for illustrative purposes ; 
other device control words are specifically described with the device 
handler description in the appendix on Peripheral Support. An attempt 
has been made to keep these control words compatible, so much of what 
is said regarding the teletype will hold true for other devices as 
well. 

The teletype device control word is structured as follows: 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



Device Unit Number 



unused 

ASCII parity bits 

= ASCII mode, 1 = image mode 

= character format, 1 = word format 

= echo on input, 1 = suppress echo 

= input, 1 = output 



The following conventions have been adopted in RTOS: 
Bit Input / Output Mode Switch 

= input mode 

1 = output mode 

(Used only where device has both input and output mode 
like a teletype. Paper tape reader is always in input 
mode and this bit is not tested.) 

Bit 1 Echo Indicator Switch 

= echo on input 

1 = suppress echo 

(Used only for teletype where characters typed on the 
keyboard may be echoed on the teleprinter.) 
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Bit 2 Data Format Switch 

= character format 

1 = word format 

Character format is available for I/O of data items 
occupying 8 bits or less. The items are stored/ re- 
trieved in byte format (two bytes per word - right 
half first) and the data item pointer and data item 
count are interpreted as the byte address and byte 
count respectively. 
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pying 16 bits or less. The items are stored/retrieved 
in right justified form from successive memory loca- 
tions (unused bits are cleared by the device on input 
and ignored on out™ it. 1 . The data item nninter and 
count are interpreted as a word address and word count 
respectively. 

Bit 3 Transmission Mode Indicator 

= ASCII mode 

1 = Image mode 

In ASCII mode 8 bit characters are handled according to 
the following conventions: 

i) characters are stored/retrieved with parity 
generation/ checking as specified by the ASCII par- 
ity bits. 

ii) nulls are ignored on input unless listed as 
terminators by the system. 

iii) input is terminated by any character in the 
list of ASCII system terminators or by the data 
item count going to zero, whichever occurs first. 
(ASCII system terminators are simply a list of ASCII 
characters masked to 7 bits) . 

iv) output is terminated by a null byte, the data 
item count going to zero, or (in the special case of 
a teletype) the input of a character, whichever 
occurs first. 

In image mode, data items are stored/retrieved in char- 
acter or word format (as specified) exactly as received 
by the hardware (no parity generation/testing, etc.) 
Input is terminated only by the data item count going to 
zero, while output is terminated by the item count going 
to zero or in the case of the teletype by the operator 
striking any key. 
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Bits 4 ASCII Parity Bits 

and 5 Control words for devices which are capable of handling 
the ASCII mode of transmission have two bits reserved 
for the specification of the parity operation required. 
The various possibilities are as follows: 

i) Input 

00 - mask to 7 bits (no parity check) 

01 - mask to 7 bits (check even parity) 

10 - mask to 7 bits (check odd parity) 

11 - same as 00 

ii) Output 

00 - channel 8 set to zero 

01 - even parity in channel 8 

10 - odd parity in channel 8 

11 - channel 8 to one 

Bits 6 

and 7 Unused 

Bits Device Unit Number 

8-15 This number is applicable only in the case of multi- 
unit device handlers such as the teletype or magnetic 
tape. The device unit number specifies the specific 
unit (of a particular device type) which is being 
referred. In the case of teletypes, both keyboard and 
printer are considered as being a part of the same de- 
vice unit. The console teletype (hardware device codes 
10 and 11) is device unit number zero. 



3.1.3 DATA ITEM POINTER 

The data item pointer is a byte address if the data is being input or 
output in character format and is a word address if the data is input 
or output in word format. 

3.1.4 DATA ITEM COUNT 

The data item count is a byte count if the data is being input or out- 
put in character format and is a word count if the I/O operation is in 
word format. 



3-4 



3.1.5 ERROR ROUTINE ADDRESS 

If an error occurs during the processing of an .IOX meta- instruction, 
the error routine address parameter is used as the return PC when the 
TASK is placed in the pending state. The contents of AC3 at the time 
of the return are used to specify the error. Error indications differ 
from device to device; possibilities for the teletype are as follows: 

AC3 = n Input of character "n" caused termination of the 
output 

AC3 = Illegal device unit number in the .IOX calling 
sequence 

AC3 = -1 Parity error on input 

AC3 = -2 Negative word count in the .IOX calling sequence 

AC3 = -3 Teletype unit number error in the .IOX calling 
sequence. 

A number of devices have no defined error conditions (e.g., high speed 
paper tape punch, incremental plotter, etc.). The error routine ad- 
dress parameter in these cases is merely a dummy parameter provided to 
maintain .IOX format compatibility. The calling sequence to these de- 
vices could be as follows : 

.IOX 

<DEVICE #> 
< CONTROL WORD> 
<DATA POINTER> 

<UA1A UJUiNl> 
<. + 1> 

<RETURN> 

3.2 DEVICE HANDLERS 

That portion of RTOS which deals with the processing of .IOX commands 
is of primary interest to the real-time user wishing to add his own 
(or modify the standard) I/O device handlers. These handlers, with 
two exceptions (real-time clock and teletype), are written as separate, 
relocatable subroutines which are linked to RTOS at load time by the 
relocatable loader. 

A device handler consists of three major sections: the device 
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initialization routine, which also includes a "next I/O" segment, the 
interrupt service routine, and the device unit control block (DUCB) . 

3.2.1 DEVICE INITIALIZATION 

The device initialization routine is called by the .IOX processor by 
using the device handler entry point orientated in logical device 
code order in RTOS in a table called 'HANTB'. These entry points are 
the interrupt service routine addresses. The location preceding each 
entry point in the device handler must contain the address of the 
initialization routine, and is used as the transfer mechanism by the 
.IOX processor. This can be easily seen by reviewing some of the 
supplied device handlers. 

The device initialization routine tests for device availability. If 
the device is available, it initiates the operation. If it is unavail- 
able, the request is queued by the "IOSTK" routine. The initialization 
section of the handler also has an entry point which may be used by 
the interrupt routine to activate an "next I/O" operation for the de- 
vice, a mechanism which should become apparent after reviewing a 
supplied device handler. 

3.2.2 DEVICE INTERRUPT SERVICING 

The interrupt service routine is responsible for responding to the 
interrupts which a device generates while in progress. It is pointed 
to by two tables in RTOS: one oriented in hardware device code order 
in the interrupt processor 'INTP', called 'DISP' and one oriented in 
logical device code order, called 'HANTB'. If a hardware device has 
not been included as part of the hardware configuration its entry in 
the 'DISP' table is replaced by the address of a routine 'NODEV' which 
will clear the interrupting device and dismiss the interrupt. 

The interrupt processor when entered first checks whether the power 
monitor option caused the interrupt if it is part of the hardware con- 
figuration. If it was the power monitor, the power fail handler '.PWR' 
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is entered. If the power monitor did not cause the interrupt or is 
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of the interrupting device and branch throu°h the correct entr v in 
the dispatch table. 

Interrupt service is performed primarily by the system routine en- 
titled 'PRIOR' (called by JSR §.SERV), which rearranges the system 
interrupt priorities and saves the machine environment in the "PRIOR" 
parameter block. The first parameter in the 'PRIOR' call is the new 
priority interrupt mask to be used while the device is being serviced. 
If desireable, this parameter may be altered dynamically by user pro- 
grams j but extreme caution is urced : 

The program then issues suitable I/O instructions to input or output 
the next data item and test the status of the device being serviced. 
In the case of character orientated devices like the teletype, paper 
tape reader and punch, or plotter most of the necessary servicing 
routines are supplied within RTOS. 

3.2.3 DEVICE UNIT CONTROL BLOCK (DUCB) 

Every device, or more specifically, every unit of every device type 
in the system is defined by static and dynamic information contained 
in the Device Unit Control Block (DUCB) , The DUCB table is contained 
as part of the relocatable device handler. 

A typical DUCB (in fact, the model on which other DUCB's are based) is 
that for the teletype, which appears as follows: 

.TTY0: 






; queue block address, if inactive 


(DTCBA) 





; variable storage location 


(DTEMP) 


JMP 0,3 


; subroutine return instruction 







; address of get -store character 






routine 


(DGSR) 


10 


; device code for TTI 


(DVCDE) 





; data pointer 


(DDADR) 
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.TTIO 
TTO0 + 3 

.TERM 
TTI0 + 3 







data count (DCNT) 

= queue available, 

1 = queue busy (DQBSY) 

= ASCII mode, 1 = image mode (DCMDE) 

address of proper parity routine (DPRTY) 

address of "next I/O" routine (DNIOR) 

interrupt data block address (out- 
put) (DIDBO) 

address of input terminator list (DTERM) 

interrupt data block address (in- 
put) (DIDBI) 

error return address (DERTN) 

device operating mode (0 - 2) (DMODE) 

-1 = break disabled, else unit # (DBRK) 



Given at the right of the comments is a list of parameter names by 
which RTOS refers to these DUCB entries. These same names are made 
into equates and used in the device handlers. 

The first DUCB entry is set to zero when the device is inactive. 
Activating a device (via an .IOX meta- instruction) results in this entry 
being chained to the TCB of the TASK awaiting service. If a device is 
already busy when the .IOX request is made, the new TCB is merely chained 
to the list of TCBs waiting for the device. This operation is performed 
by the IOSTK routine (called by JSR @.STAK), and results in a structured 
equivalent to the pending TCB queue. 

The "subroutine return instruction" provides an "execute" facility in 
order for the device handlers to execute specific instructions (e.g., 
I/O commands) without destroying their re-entrant nature. The instruc- 
tion is merely stored preceding the return command and a JSR to the 
instruction is issued. As the DUCBs are unique to each device, handler 
re-entrancy is preserved. 

The next location of the DUCB is used to save the address of a get/store 
character /word routine. This address can be a fixed entry or it can be 
taken from the table '.BTAB' in RTOS by the initialization section of 
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the handler. This table has the following entries: 

.BTAB+1: SCHRP Store character (byte mode) 

GCHRP Get character (byte mode) 

STCHR Store character (word mode) 

GTCHR Get character (word mode) 

The fourth DUCB location contains the device code for the hardware 
device which the DUCB describes. The next two entries following this 
are for the data item pointer and data item count. These are either 
in byte or word format depending on the word format indicator (bit 2 
of the control word) . 

The queue availability switch is set when a call to the device ini- 
tialization section of the handler is made. It is used by the routine 
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does not change the unit availability switch while the initialization 
routine is testing it. It is reset before the operation is initiated 
if the device is available or after the request is stacked in the pend- 
ing queue for that device. 

The mode indicator has the same meaning as bit 3 of the device control 
word. The address of the parity routine is taken from a table of 
parity checking generating subroutine addresses starting at '.PTAB+1'. 
The address to be taken from this table is dependent on whether the 
operation is input or output and the value of the ASCII parity bits. 
The table has eight entries as follows : 

BIT7 ;Mask to 7 bits (input) 

BIT7 ;Mask to 7 bits (output) 

TEVEN ;Test even parity 

GEVEN ; Generate even parity 

TODD ;Test odd parity 

GODD ; Generate odd parity 

BIT7 ;Mask to 7 bits (input) 

CHN8 ;Set channel 8 to one (output) 

The next I/O routine address is stored in the twelfth entry of the 
DUCB table. It serves as the entry point for starting the next pending 
I/O operations for the device. Entries 13 and 15 provide the addresses 
of the output and input interrupt data blocks respectively. These data 
blocks are usually the part of the 'PRIOR' parameter block that contains 
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the machine status before it was interrupted. 

The fourteenth entry of the DUCB provides the address of a list of 
terminator characters that will terminate ASCII input. This list must 
be terminated by a -1. The list used can be set up by the user. The 
current version of RTOS has a list of ASCII terminator characters 
starting at '.TERM' as follows: 

.TERM: 



177 


Rub out, delimiter 


15 
12 


Carriage return, control M 
Line feed 


33 

3 

-1 


Escape 

End of text, end of message, control C 



The error return address is taken directly from the .IOX calling se- 
quence if the device can generate an error condition. The operating 
mode is usually fixed at the time of handler design. For example the 
card reader can only operate in input mode and so this parameter would 
be while it would be a 1 for the high speed paper tape punch to 
indicate output mode. The teletype can have an echo on input, input 
only, or output only mode and so this parameter is a variable in the 
case of the teletype. 

It should be noted that the final entry in the DUCB shown above is 
necessary only for the teletype (the .BRK facility) and will normally 
not be used for other device handlers. It should also be clear that 
some of the DUCB entries are not required for some devices types (e.g., 
output only devices do not require an input interrupt data block ad- 
dress or input terminator list, devices with no error return conditions 
require no error return address, etc.). Unused entry locations may be 
used for storage of constants or handler variables. 

3.2.4 DEVICE OPERATION COMPLETE ROUTINE 

It is important to be aware of the fact that when termination of an .IOX 
operation causes a device to become free, another request may be waiting 
to be activated. In order to properly handle the complexity of inter- 
acting interrupt levels at this point a "pseudo-TASK" (with priority 
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level 0) is created by RTOS to initiate the next operation request. 
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have been provided for when the 'JOBS' parameter was set during RTOS 
system generation. A TCB must be provided for each interrupting hard- 
ware device including the teletype and real time clock. Failure to 
provide sufficient TCB storage will cause a HALT at location 'QSPOP+4' 
or a branch to a user program at ' .SHUT depending on the value of 
'SHALT'. 

3.3 RTOS DEVICE SERVING PROGRAMS 

M3TYV Q-f "Ht_£ subroutines with. iii RTOS necessary for c ervicin rr "*~^e *"°i °- 
type have been written re-entrantly. The reason for this is that at 
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and its handler, if developed in a general -purpose and flexible 
enough manner, will provide major services for almost all other de- 
vice handlers that are included or may be developed for system hard- 
ware devices. A brief description of the four most common routines 
appears in the following sections. 

3.3.1 DEVICE CONTROL BLOCK SETUP (.DUCB) 

This subroutine is entered with AC3 containing the address of the con- 
trol block for the device being initiated and the device control word 
is contained in AC0. The routine sets the ASCII/image mode and opera- 
ting mode indicators, claculates and saves the addresses for the get/ 
store character and parity generating/checking routines, and obtains 
the data item pointer and count from the .IOX calling sequence. 

After the DUCB is initialized, the first I/O operation is initiated. 
If the operation is an input, the routine obtains the device code from 
the DUCB and by using the temporary storage and return provided in the 
devices DUCB, it executes an NIOS to start the device. If output is 
requested another subroutine 'OUT' will be called to get the character, 
generate the correct parity, and output the first character to the de- 
vice. It should be noted that since this routine was developed for 
the teletype which only has the device code of the keyboard in the DUCB, 
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any other device handler trying to use '.DUCB' for initiating output 
operations must supply a device code one less than its true code. 

3.3.2 INPUT HANDLER (.CHIN) 

This re-entrant routine is used to handle input interrupts on the 
teletype and similar byte oriented devices. It is entered with the 
previous machine status saved and the new character as it came from 
the device in AC0. 

The routine first checks whether the device is being run in ASCII or 
image mode. If it is in ASCII mode, a check is made to see whether a 
null character has been entered in which case it is ignored. A parity 
check is then performed and if not correct the error return is taken. 
If correct parity is found, the routine then checks whether a match 
between the list of terminator characters and the input character (now 
masked to 7 bits) is present. If it is the input operation is complete 
and if not, the character is stored in the input buffer, and another 
request made if the data count has not gone to zero. 

3.3.3 OUTPUT HANDLER (.CHOT) 

This re-entrant routine is entered with AC2 containing the address of 
the device unit control block and is used to handle output interrupts 
on the teletype and similar character oriented devices. 

The data count is checked upon entry to this routine. If it has gone 
to zero, the output operation has been completed and the end of output 
completion section 'IOEND' is entered. If data remains to be output, 
the next character is obtained and the output device started using 
the routine 'OUT'. The interrupt is then dismissed with the routine 
•DISIN'. 

3.3.4 INPUT/ OUTPUT REQUEST SETUP (.TTIO) 

This routine, used by the teletype .IOX handler and referred to as the 
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"next I/O" routine, is entered when it is determined that the requested 
device is now available for the next I/O request. It sets the I/O 
queue indicator of the DUCB to the available status, restores AC2 to 
the address to point to .IOX + 1 and stores the error return address 
in the DUCB. 

3.3.5 MACHINE STATUS SAVE ROUTINE (PRIOR) 

'PRIOR' is a module within the RTOS system that an interrupt connected 
routine calls to save the environment of the TASK that was interrupted. 
It also provides a mechanism whereby an interrupt servicing routine may 

The calling sequence is shown below and shows that 'PRIOR' stores the 
environment of the interrupted routine in the storage block just fol- 
lowing the JSR, to the "PRIOR" subroutine. An entry point '.SERV 
in the RTOS program is provided for use by the device handlers. 



JSR PRIOR 

NMASK 















DUCB 



New hardware priority word 

Old priority word storage 

Carry storage 

AC0 storage 

AC1 storage 

AC2 storage 

AC3 storage 

Program counter storage 

Address of device control block 



The subroutine 'PRIOR' is entered with AC2 and AC3 having been pre- 
viously saved in locations 'SAC2' and 'SAC3', respectively, by the 
interrupt processor 'INTP'. 

3.3.6 MACHINE STATUS RESTORE ROUTINE (.DISN) 

The RTOS executive routine ' .DISN' provides an interrupt service routine 

with the means to perform the following functions: 

i) restore the operating environment of the interrupted 
routine, 
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ii) restore the hardware interrupt priority, and, 
iii) return to the interrupted routine. 

It is entered with AC2 containing the address of the interrupt data 
block. The interrupt data block address is taken as the address of 
where the carry bit is stored, i.e., three locations past the JSR 
PRIOR. 

3.3.7 INPUT/OUTPUT REQUEST STACKER (IOSTK) 

This system routine is called when the I/O request must be queued for 
the device because a previous task is already using the device. An 
entry point '.STAK' within the RTOS program is provided for use by the 
device handlers. 

3.3.8 END OF I/O OPERATION ROUTINE (. IOEND) 

This routine is used to handle the end of I/O operations for a device 
handler at either the interrupt or system level. When entered on the 
interrupt level, the address of the interrupt data block will be in 
AC0. At the non-interrupt level, AC0 will contain a zero. 

Upon entry, if it is found that the DUCB is not available, this routine 
will create a job at priority zero to perform the end of I/O operation 
at the non-interrupt level. 

If while in the .IOEND routine, it is determined that another request is 
pending, the routine will create a job of priority zero to start the 
next I/O operation on the device. 
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CHAPTER 4 



The initialization program 'RTIN' is used to initialize stacks and 
clear switches in the RTOS system. The first section of the routine 
zeros system switches and sets all the device handlers to the avail - 

aVilo ctoto TVio c-vrc-f-OTn t c iTiitioll^r co-f- -f-n o T*»Y*-i r\-rn i--\r r*-F *7orT\ -hVio 

hardware mask is made zero, the system is set in USER MODE, the real 
time clock is set inactive, the clock queue and the TCB queue pointers 
are both set to zero. 

All the .XMIT/.RCV channel status table entries are made inactive by 
setting them all to zero. The task control block and clock queue 
stacks are initialized by linking each block together in a form simi- 
lar to that described in section 2.1.2 for pending TASK. The break 
request is set inactive by setting the break character '.BCHR' to -1. 

The last operations performed by the initialization program are to do 
an IORST, enable the interrupt facility by the INTEN instruction, and 
to jump to the start of a user TASK which must be given a label 'START' 
which is declared as an entry point in the user program. 

The queue availability switch of each device handler must be zeroed 
by the initialization program. The address of this location (the 
first in the device's DUCB table) is available to the initialization 
program by means of a second entry point in the handler and usually 
defined using the first four characters of the handler interrupt entry 
point followed by a digit "1". 
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APPENDIX A 

SYSTEM G ENERATION 

System generation allows the user of the Real Time Operating System 
to define the characteristics of his operating environment (the num- 
be of .XMIT/.RCV channels, I/O devices on the system, speed of the 
real time clock, etc.). 

The input to an RTOS system generation is the set of relocatable 
source and binary paper tapes of RTOS, the initialization program 
(RTIN) , and handlers for standard I/O devices . When source tapes 
are ordered in the customer software package, the user can easily 
change the hardware configuration parameters , the operating system 
specifications, and add or modify device handlers. 

The RTOS system supplied supports a hardware configuration consisting 
of at least 4K core memory, the real time clock, the high speed paper 
tape reader and punch, and the console teletype. The operating sys- 
tem allows sixteen user TASKS, and eight .XMIT/.RCV communication 
channels. The real time clock is set to operate at 100 Hertz. 

A.I RTDS PARAMFTFR TAPF. 



The parameter tape provides a definition of all system variables that 
must be set by the user to tailor RTOS to his installation. The 
system/device definitions provided on this tape are described in section 
D.2. 

Unless the user is adding new device handlers not provided for in the 
released RTOS system or is changing the standard logical device numbers 
of the system, the parameter tape is the only tape that must be 
modified by the user. A reassembly of RTOS and the initialization 
program using the new parameter tape is required to tailor the operating 
system to the user's environment. 
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A listing of the RTOS Parameter Tape is provided with the supplied 
program package. Note that all symbols have been declared using the 
.DUSR pseudo-op. They will therefore not appear in the assembly's 
symbol table output. Further, loading of the parameter tape can be 
skipped on pass 2 or saved permanently as part of the assembler. 

Most of the system definition parameters described in section D.2 
must be set to a value of or 1 depending on whether the device or 
option is present or not on the system. Other parameters can take on 
values greater than 1 and will now be described in more detail than 
appears in D.2. 

CHAN Number of .XMIT/.RCV channels on the system. 

It should be given a value greater than zero. For 
each channel that is defined, an entry is made in each 
of the channel message and status tables. 

FREQ Real time clock frequency. 

= AC line frequency 

1 = 10 Hertz 

2 = 100 Hertz 

3 = 1,000 Hertz 

JOBS Maximum number of parallel TASKS allowed in the system. 
This must be set to the total number of user TASKS and 
hardware devices tied to the interrupt facility. 

SHALT System Resources Depleted Parameter 

A "0" implies the system should HALT if enough TASK 
control blocks were not defined because the value of 
'JOBS' was too small. 

A "1" implies the system should branch to a user supplied 
program with an entry point called '.SHLT' if the above 
condition occurs. 

TTYS Number of teletypes in the system. 

It is assumed that all Nova computer systems will have 
at least a console teletype and so this value should be 
set to at least "1". 

If additional teletypes are added to the system this 
value should be increased and the user must remember to 
set up the DUCB tables and entry points in the logical 
device number and interrupt entry point tables. 
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A. 2 PROGRAM ASSEMBLY 

Once the user has obtained a new parameter tape, he can then proceed 
to assemble the Real Time Operating System and the initialization 
program 'RTIN'. Each of these programs requires that the parameter 
tape be the first tape in the assembly. 

These programs should be assembled using either Extended Assembler 
(091-000017) or the DOS Assembler (088-000001) . 

If the user desires to assemble the RTOS system absolutely using the 
absolute assembler (091-000002), the code for relocation, interpro- 
gram communication, and conditional assembly must be removed. Loca- 
tion statements must be inserted into RTOS, the initialization, and 
the device handler programs to provide starting addresses. An equate 
table must be made for interprogram communication. 

A. 3 SYSTEM LOADING 

After generating relocatable binary tapes for all RTOS system and user 
programs , the user is ready to load his system. The Extended Reloca- 
table Loader (091-000038) is first loaded by the standard binary loader 

and is then Used to load the relnratflhlff h-inn-rv tanp? Fnr nnpratino 

instructions the Relocatable Loader Manual (093-000039) should be re- 
ferenced. 

The starting address of the user TASKs must be labelled 'START* and 
declared as an entry point (.ENT). 

A. 4 SYSTEM STARTUP 

The system should be started at location 'INIT' after loading all the user 
TASKs, RTOS system programs and required device handlers. The initializa- 
tion program when completed branches to the start of the user TASKs at 
'START'. 
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APPENDIX B 

WRITING A DEVICE HANDLER 

The purpose of this appendix is to outline a step by step procedure 
for adding a new device handler to the Real Time Operating System. 
The I/O calling sequence, the device handler implementation, and the 

^llKymitinp pntrv nnintc i*ri th -i n RTOQ -t-Via*- ran lio nc<J liavo oil Kaon 

described in Chapter 3: Device Handler Implementation. 

For the purpose of illustration, we shall call the device entry 
point .DEV and its definition parameter will be DEVICE. The label 
DEVICE will be edited into the RTOS parameter tape and given a value 
of "1" to tell the system that this device is to be included in the 
system. 

To clarify what is said in the following sections, the user planning 
to implement his own device handler should review some of the supplied 
handler listings. 

B.l Entry Point Definition 

The device handler entry point must be defined in two tables within 
the RTOS system. The first table 'HANTB' is a list of entry points 
oriented in logical device code order. The supplied system has defined 
logical unit numbers for most of the standard I/O devices that can be 
supplied with a Nova computer. (See section 3.1.1: LOGICAL DEVICE 
NUMBER) . This table could be expanded by adding the new device handler 
entry point at the end of the table or modified by changing one of the 
present device assignments to the new device. 

To include the new device as logical device number ten at the end of 

the present list, the code 

. IFE DCCM 
.IOBAD 

.ENDC 
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.IFN 


DEVICE 


.EXTN 


.DEV 


.DEV 




• ENDC 





;DEVICE 10 lj8 

should be added to the existing table. It must precede the label 
'HANTE' which is used to point to the end of the handler table. 

To include the new device as logical device number four instead of 
the incremental plotter, the code 



; DEVICE 4 



should be changed to read 



.IFN 


PLOT 


.EXTN 


• PLT 


.PLT 




.ENDC 




.IFE 


PLOT 


read 




,IFN 


DEVICE 


.EXTN 


.DEV 


.DEV 




.ENDC 




.IFE 


DEVICE 



; DEVICE 4 



The second table which must be supplied with the interrupt servicing 
routine entry point is the interrupt dispatch table 'INTP'. The 
entry in this table must correspond to the device code assigned to 



the hardware device. If the device code was 30 
be added to the end of the table after 



(8) 



the code that must 



is as follows: 



.IFN 
.EXTN 
.DCCM 
.ENDC 



.IFE 

NODEV 

.ENDC 

NODEV 
NODEV 
NODEV 

.IFN 
.DEV 
.ENDC 



DCOM 

.DCOM 



:Data Communication (Code24) 



DCCM 



DEVICE 



CODE 25 
CODE 26 
CODE 27 

;DEVICE CODE 30 
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B.2 INITIALIZATION 

Initial entry to the device handler is provided through the .IOX 
meta- instruction. The portion of RTOS that processes the .IOX call 
creates a TASK control block, checks that the device number is within 
the allowed range and is defined on the system, checks that the word 
count is greater than or equal to zero, and then branches to the 
initialization section of the device handler. If during the .IOX call 
processing, the count is found negative, the .IOX call is set up to 
take the error return with AC3 - -2. If it was not a legal device 
number, the error return is made with AC3 = 0. 

me entry to tne initialization section is provided by putting its 
address immediately preceding the interrupt entry point. The .IOX 
servicing program loads AC3 with the interrupt entry point address 
'.DEV' from the 'HANTB* table and does a JMP §-1,3 to enter the initial- 
ization section of the handler. 

Upon entering the initialization program, all system status information 
has been saved in a TASK control block whose address is contained in 
AC2. Accumulator zero contains the device control word from the .IOX 
calling sequence. The program must now check whether the device is 
available to service the new request or the request must be stacked to 
await completion of previous requests. 

To insure that the DUCB is not modified by the interrupt servicing sec- 
tion of the device handler while it is being accessed from the initial- 
ization section of the handler, the eighth entry ('DQBSY') of the 
DUCB is set non-zero to indicate the queue is busy. The check is then 
made by loading the first entry of the DUCB. A zero value means the 
device is inactive and the desired I/O request can be initiated imme- 
diately. A non-zero value means the request must be put into the stack 
of TASKS awaiting to perform I/O on the called device. The TASK can 
be put in the stack by the 'IOSTK' routine which may be entered by a 
jump indirect through a page zero variable called '.STAK' and defined 
as an entry point in the RTOS program. 
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If the device is available to service the request, the initialization 
program then branches to the "next I/O" section of the handler. 

B.3 NEXT I/O REQUEST SERVICING 

This section of the handler is used to complete the DUCB setup for the 
I/O request once the device is available. It is entered directly from 
the initialization section of the handler if the device was available 
at the time of the .IOX call or from the interrupt servicing section 
if the previous request was completed. The address of this routine is 
the eleventh entry of the DUCB table and is also used by the 'IOEND' 
routine of RTOS when the end of the previous I/O operation is being 
completed and additional requests are stacked for the device. 

The next I/O routine must be entered with the accumulators setup as 

follows : 

AC0 = device control word (2nd .IOX parameter) 

AC1 = 

AC 2 = address of the task control block 

AC3 = address of the device unit control block (DUCB) 

This occurs automatically when the end of I/O operation of RTOS is per- 
formed and must be the case when entering from the initialization sec- 
tion. 

The routine should first save the TCB address as the first entry in the 
DUCB and zero the I/O queue availability switch in the DUCB. It must 
set up the data pointer, data count, and error return storage locations 
within the DUCB from the .IOX call parameters. The device control word 
is used to initialize the device operating mode switch, the address of 
the get/store character routine, the address of the proper parity 
routine, and the character mode indicator. 

The device operating mode switch (parameter 'DMODE') and the character 
mode indicator (parameter 'DCMDE') can be set directly from the control 
word, their values being 0,1,2 or 0,1 respectively. The address of the 
get/store character routine can be obtained from the table '.BTAB' in 
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RTOS and stored as the 'DGSR' parameter in the DUCB. The correct en- 

format switches of the control word. The address of the parity rou- 
tine can be obtained from the table '.PTAB' in RTOS and stored as the 
'DPRTY* parameter in the DUCB. The correct entry is determined by 
checking the input/output mode switch and the ASCII parity bits of 
the control word. 

After the DUCB has been completely initialized, the routine should 
initiate the first I/O operation. If the device is operating in the 
input mode, this need only be an NIOS instruction to start the device. 
If output mode is used, the routine should get the first word or char- 
acter and transmit it to the device. After starting the device in 
either input or output mode, the program should return to the TASK 
scheduler by the .QUIT meta- instruction. 

If the handler is being developed for a teletype-like device (byte 
oriented) , many of the routines written into RTOS can be used. This 
is the case for the high speed paper tape reader/punch and the plot- 
ter handlers. Routines that are commonly used and have been written 
re-entrantly like '.DUCB' and ' .TTIO' have been described in sections 
3.3.1 and 3.3.4 respectively. 

B.4 INTERRUPT SERVICING 

The interrupt servicing section of the device handler is entered di- 
rectly from RTOS when it responds to the hardware interrupt. It per- 
forms the entry via an indirect jump through the interrupt dispatch 
table 'DISP' by getting the device code from the interrupting device 
through an interrupt acknowledge command 'INTA' and adding this num- 
ber to the address 'DISP'. 

Standard practice in handler development is to branch to the subrou- 
tine 'PRIOR' as the first operation in the servicing program. This 
can be performed by an indirect jump through the page zero entry point 
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'.SERV and is used to rearrange the hardware priorities, save the 
system status, and enable the interrupt facility again. The return 
from this subroutine is to 10 locations past the JSR with AC2 con- 
taining the address of the device unit control block. For a detailed 
description of the subroutine 'PRIOR', see section 3.3.5. 

If it was an input operation, the routine must read the character/word 
from the device, perform proper parity checking, save it in the input 
buffer, and test if more input is required and restart the device if 
necessary. If the operation was performing output, the routine must 
test if further characters/words are to be sent to the device and if 
so, initiate the next output operation. 

If another I/O operation must be performed, the interrupt should be 
dismissed after the operation is initiated. This can be done by en- 
tering the ' .DISN' routine of RTOS with AC2 pointing to the interrupt 
data block. This address is stored in the 'DIDBO' parameter of the 
DUCB for an output device and in the 'DIDBI' parameter for an input 
device. The ' .DISN' routine will restore the hardware priorities and 
machine status to that found previous to the occurrence of the in- 
terrupt . 

To initiate another I/O operation on a byte-oriented device like the 
teletype special re-entrant routines have been supplied in the RTOS 
program. These routines '.CHOT' and '.CHIN' can be used to initiate 
the next output or input operation respectively, in a manner similar 
to the supplied high speed paper tape punch and reader handlers. 

If the device is not byte-oriented or cannot be handled like a tele- 
type, the user writing the handler must provide the necessary code to 
start the next I/O operation. This may have been written for the 
"next I/O" servicing section or may have to be supplied for the in- 
terrupt "next I/O" request. 

For an output operation, the next I/O portion must test if further out- 
put is required and if it is not, enter an end of output operation 
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phase. This routine is supplied in RTOS with the entry point being 
defined as '.CHRO'. If further output is required, the routine must 
use the get character /word subroutine, whose address has been entered 
in the DUCB as the 'DGSR' parameter, to get the next data item, to 
send it out to the device, and to dismiss the interrupt via the ' .DISN' 
routine . 

For an input operation, the next I/O routine must check the parity of 
the newly entered data item if operating in the character mode and 
then to store the data into the input data buffer via the routine whose 
address is the ! DGSR ! parameter of the DUCB. The routine must then 
test if further input is required and if it is not, enter an end of in- 
put operation phase. A routine for this purpose is supplied in RTOS 
with an entry point defined as '.CHRI'. If additional input data is 
required, the device should be reactivated and the interrupt dismissed 
via the RTOS routine starting at entry point '.DISN'. 
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APPENDIX C 

PERIPHERAL SUPPORT SUNMARY 

This appendix contains a summary sheet for each of the standard device 
handlers. The sheet gives the format taken by the device control word 
in the .IOX calling sequence. It also provides a summary of the pos- 
siuj.e normax anu error returns xrom tue jianuler arm. tiie meaning that 
AC3 takes in these cases. 

Additional sheets for other device handlers will be added to this 
appendix as the handlers are made available. Handers currently avail- 
able include: 



Device Name 


Page 


Teletype 


C-2 


High speed paper tape reader 


C-3 


High speed paper tape punch 


C-4 


Incremental plotter 


C-5 


Card reader 


C-6 


Line printer 


C-7 


Analog to digital converter 


C-8 


Multiple teletype system 


C-9 
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TELETYPE DEVICE CONTROL WORD 



12 3 4 5 6 7 



9 10 11 12 13 14 15 



TTY UNIT NUMBER 



Unused 

Parity Bits (Ignored in image mode) 
Input Mode 

00 - Mask to 7 bits, ignore parity 

01 - Test even parity 

10 - Test odd parity 

11 - Mask to 7 bits, ignore parity 
Output Mode 

00 - Set channel 8 to zero 

01 - Generate even parity 

10 - Generate odd parity 

11 - Set channel 8 to one 



- ASCII Mode 

1 - Image Mode 

- Character Format 

1 - Word Format 

- Echo on Input 

1 - Suppress EcnO on input 

- Input 

1 - Output 



NORMAL RETURN CONDITIONS 



AC3 = -1 
AC3 = n 



AC3 







Data count went to zero 



Input of character "n", either a null or from the list 
of terminators, caused termination of input 

Data output was terminated by a null character 



ERROR RETURN CONDITIONS 



AC3 - n 

AC3 = 

AC3 = -1 

AC3 = -2 

AC3 - -3 



Input of character M n" caused termination of the output 
Illegal device unit number in .IOX calling sequence 
Parity error on input 

Negative word count, in .IOX calling sequence 
Teletype unit number error in .IOX calling sequence. 
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HIGH SPEED PAPER TAPE READER CONTROL WORD 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



Parity Bits 

00 - Mask to 7 bits, ignore parity 

01 - Check even parity 

10 - Check odd parity 

11 - Mask to 7 bits, ignore parity 

- ASCII Mode 

1 - Image Mode 

- Character Format 

1 - Word Format 

Unused 

(Input only operation available) 



NORMAL RETURN CONDITIONS 



AC3 = -1 
AC3 = n 



Data count went to zero 

Input of character "n", either a null or from the 
list of teiminators , caused termination of input. 



ERROR RETURN CONDITIONS 



AC3 = 
AC3 = -1 
AC3 = -2 



Illegal device unit number in .IOX calling sequence 

Parity error on input 

Negative word count in .IOX calling sequence 
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HIGH SPEED PAPER TAPE PUNCH CONTROL WORD 



12 3 4 5 6 7 



9 10 11 12 13 14 15 



Parity Bits (Ignored in Image Mode) 

00 - Channel 8 Zero 

01 - Generate Even Parity 

10 - Generate Odd Parity 

11 - Channel 8 One 

- ASCII Mode 

1 - Image Mode 

- Character Format 

1 - Word Format 

Unused 

(Output is only operation available) 



NORMAL RETURN CONDITIONS 



a *-"7 _ ri 

rtto - yj 
AC3 = 1 






Data count went to zero 



ERROR RETURN CONDITIONS 



AC3 = 
AC3 = -2 



Illegal device unit number in .IOX calling sequence 
Negative word count in .IOX calling sequence 
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PLOTTER CONTROL WORD 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



Unused 

(6 Bit instruction assumed) 

- Character Format 

j. - (tuiu rufmat 

Unused 

(Output is only operation available) 



NORMAL RETURN CONDITIONS 



AC3 = 
AC3 = -1 



Data output was terminated by a null character 
Data count went to zero 



ERROR RETURN CONDITIONS 



AC3 = 
AC3 = -2 



Illegal device unit number in .IOX calling sequence 
Negative word count in .IOX calling sequence. 
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CARD READER CONTROL WORD 



l 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



Unused 

- ASCII Mode 

1 - Card Image Mode (Word Format only) 

- Character Format 

1 - Word Format 

Unused 

(Input is only operation available) 



NORMAL RETURN CONDITIONS 



AC3 



Card read correctly 



ERROR RETURN CONDITIONS 



AC3 = 





AC3 = 


-1 


AC3 = 


-2 


AC3 = 


1 


AC3 = 


2 


AC3 = 


4 



Illegal device unit number in .IOX calling sequence 

Card reader is not available (not on line) 

Negative word count in .IOX calling sequence 

A card has failed to move properly through the reader 
or an error has been detected in the circuitry. 

A card was not brought in from the hopper 

The card hopper is empty or the stacker is full. 
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LINE PRINTER CONTROL WORD 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



'/////, 



Unused 

(7 Bit ASCII Assumed) 

- Character Format 

1 - Word Format 

Unused 

(Output is only operation available) 



NORMAL RETURN CONDITIONS 



AC3 = 
AC3 = -1 



Data output was terminated by a null character 
Data count went to zero 



ERROR RETURN CONDITIONS 



AC3 = 
AC3 = -2 



Illegal device unit number in .IOX calling sequence 

UJ.UV, pxj.111.cx nui. avaiiaujc (Jjui, uii xxnc ) puwci UJ.X 
nr nut n-F ranprl 

Negative word count in .IOX calling sequence 
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ANALOG TO DIGITAL CONVERTER CONTROL WORD 



12 3 


4 5 6 7 


8 9 


10 11 12 13 14 15 


W//////////////////W//M. 








. . . AnCV rhnnnnl 








ITnn<;prl 



NORMAL RETURN CONDITIONS 



AC3 = -1 



Data count went to zero 



ERROR RETURN CONDITIONS 



AC3 = 
ACS = -2 



Illegal device unit number in .IOX calling sequence 
Negative word count in .IOX calling sequence. 
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MULT IPLE TELETYPE SYSTEM 

Provided with RTOS is a handler for two additional teletypes . These 
are included in the program if at assembly time the parameter tape 
specifies that TTYS is greater than one. Only a device unit control 
block and the interrupt servicing logic for the teletype input and 
output are necessary to implement an additional teletype under RTOS. 

The two teletypes referred to as TTY Unit Numbers 1 and 2 are imple- 
mented in the .MTTY handler service device codes 50,51 and 40,41 

rpcwrt -i Vipl *r 

To implement other teletypes on the system, tape six of RTOS would 
need to be modified so the necessary entries are made in the interrupt 
and the teletype unit dispatch tables. 

The control word for the additional teletypes has exactly the same 
format as for the console teletype described on page C-2. 
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APPENDIX D 
RTOS VARIABLE DEFINITIONS 

The Real Time Operating System has a set of reserved words con- 
sisting of the eight meta- instructions (.IOX, .WAIT, etc.), the 
system definition parameters (JOBS, TTYS, TAPE, etc.), the de- 
vice handler names (.PTR, .DSK, etc.), and the entry points de- 
fined in RTOS (.JOB., .STAK, etc.) and the initialization program 
(START) . These reserved words cannot be used as variable names 
in user programs except as their usage pertains to RTOS. The 
meaninp and n^aup nf thp<;p va-H ah"lp<; i q Hpfinprl hpl hm 

D.l RTOS META- INSTRUCTIONS 

.BRK - is a meta- instruction (to be used as a special purpose 
command) which allows input of a specified ASCII char- 
acter to interrupt the normal operation of RTOS. 

.FORK - is the RTOS meta -instruct ion for the creation of par- 
allel processes (i.e., additional TASKS). 

.IOX - is the meta- instruction that handles standard I/O 

operations within RTOS, initiating an activity on the 
specified I/O device. 

.PTY - is the meta- instruction to alter the priority of the 
current TASK, within the range 0-255 lo (0 being the 
highest) . 

.QUIT - is the RTOS call to terminate a TASK. 

.RCV - is the second half of the meta -instruction pair for TASK 
synchronization and communication. It enables the recep- 
tion of a "synchronization signal" sent by an .XMIT in- 
struction over a specified channel. 

.WAIT - is the meta- instruction used to delay the execution of 
the current TASK for a specified time interval. 

.XMIT - is the first half of a complementary pair of meta-instruc- 
tions provided for TASK synchronization and inter-TASK 
communication. It causes transmission of a "synchroniza- 
tion" signal over a specified channel. 



D-l 



D.2 RTOS SYSTEM DEFINITION PARAMETERS 

These parameters are all defined on the system parameter tape that 
is tailored to each installation and is used when assembling the 
RTOS mainline and initialization programs. 



NAME VALUE 



A2D 

CARD 

CHAN 

DCOM 

DISK 
FREQ 
HSP 

HSR 

JOBS 

PLOT 

PRINT 

PWRFL 

SHALT 



or 1 

or 1 

+ ve 

or 1 

or 1 
0,1,2,3 
or 1 

or 1 

+ ve 

or 1 

or 1 

or 1 

or 1 



PLACES 
USED 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 

RTOS 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 
RTIN 

RTOS 



DESCRIPTIONS 

Analog to digital converter definition. 

Card reader definition. 

Number of .XMIT/.RCV channels in the 
system. 

Data communications multiplexer defi- 
nition. 

Fixed head disk definition. 

Real time clock frequency. 

High speed paper tape punch definition. 

High speed paper tape reader definition. 



Maximum number of parallel tasks allowed 
in the system. 

Incremental plotter definition. 



Line printer definition. 



Power monitor / auto restart option 
definition. 

System resources depleted definition. 
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NAME VALUE PLACES DESCRIPTIONS 
USED 

TAPE or 1 RTOS Magnetic tape definition. 
RTIN 

TTYS > or =1 RTOS Number of teletypes in the system. 
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DEVICE HANDLER NAMES 



The following list of names is reserved for device handlers in RTOS. 
As additional devices are interfaced to the Nova family of computers 
and new device handlers become available, this list of names will be 
expanded. The first name is the interrupt entry point while the 
second name is the start of the device unit control block in the 
handler . 



ADCV, 


.ADC1 


CDR, 


.CDR1 


XJCOM, 


.DCM1 


DSK, 


.DSK1 


LPT, 


.LPT1 


,MTA, 


.MTA1 


PLT, 


.PLT1 


FTP, 


.PTP1 


.PTR, 


.PTR1 


,PWR 




,TTI1 


.TTY1 


.TT01 




.TTI2 


.TTY2 


.TT02 





analog to digital converter (4032) 

card reader (4016) 

data communications multiplexer (4026) 

fixed head disk (4019) 

line printer (4034) 

magnetic tape (4030) 

incremental plotter (4017) 

high speed paper tape punch (4012) 

high speed paper tape reader (4011) 

power monitor / automatic restart option (XX06) 

teletype unit 1 (device codes 50,51) 

teletype unit 2 (device codes 40,41) 
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D.4 


SYSTEM ENTRY POINTS 






NAME 


VALUE 


PLACES 
USED 


DESCRIPTION 


.BCHR 


-ve = inactive 
+ve = break char. 


RTOS 
RTIN 


Break character storage. 


.BTAB 


.NREL 
address 


RTOS 

Device 

Handlers 


Address of table of get/ 
store character/word sub- 
routine addresses . 


.CHIN 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to handle an input 
interrupt from a byte 
oriented device. 


.CHOT 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to handle an output 
interrupt from a byte 
oriented device. 


.CHRI 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to dismiss an input 
interrupt at the end of an 
input operation. 


.CHRO 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to dismiss an output 
interrupt at the end of an 
output operation. 


.CLK. 


.NREL 
address 


RTOS 
RTIN 


Address of the clock count 
down interval queue. 


.CPNT 


.NREL 
address 


RTOS 
KTIN 


Address of the first entry in 
the clock pending stack. 


.CPTY 


0-255 lQ 


RTOS 
RTIN 


Priority of the currently 
executing TASK. 


.CST. 


.NREL 
address 


RTOS 
RTIN 


Address of .XMIT/.RCV chan- 
nel status table. 


.CSTK 


.NREL 
address 


RTOS 
RTIN 


Address of the stack of clock 
queue entries. 


.CUCB 


= inactive 

^0 clock active 


RTOS 
RTIN 


Clock active switch. 


.DCB1 


.NREL 
address 


Device 
Handlers 


Entry point in the .DUCB 
routine to initiate the first 



I/O instruction 
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System Entry Points (cont'd) 



NAME 


VALUE 


PLACES 
USED 


DESCRIPTION 


.DISN 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to restore the pre- 
vious machine status and 
dismiss an interrupt. 


.DUCB 


.NREL 
address 


RTOS 

Device 

Handlers 


Routine to set up the de- 
vice unit control block 
for . IOX calls . 


.IOER 


.NREL 
address 


RTOS 

Device 

Handlers 


.IOX unit number error re- 
turn subroutine. 


.IOEND 


.NREL 
address 


RTOS 

Device 

Handlers 


Address of a routine to 
handle end of I/O operations 


.JOB 


.NREL 
address 


RTOS 
RTIN 


Address of pending job 
TCB's. 




ik.rr*T"T 

.1NKDL, 

address 


K1UO 

RTIN 


rtUureSS 01 iiisi ciai; jji 

job pending stack. 


.JSTK 


.NREL 
address 


RTOS 
RTIN 


Address of stack of TCB 
addresses to be put in the 
pending queue. 


.PMSK 


0--177777 g 


RTOS 
RTIN 


Hardware mask for currently 
executing TASK. 


.PTAB 


.NREL 
address 


RTOS 

Device 

Handlers 


Address of table of parity 
checking/generating sub- 
routine addresses. 


.QPNT 


.NREL 
address 


RTOS 
RTIN 


Address of first entry in 
job queue stack. 


.QSTK 


.NREL 
address 


RTOS 
RTIN 


Address of pending job TCB 
address storage area. 


.QUE. 


.NREL 
address 


RTOS 
RTIN 


Address of first TCB to be 
queued . 


.RTC. 


.NREL 
address 


RTOS 
RTIN 


Address of first entry in 
clock count down interval 
queue . 


.SERV 


.ZREL 
address 


Device 
Handlers 


Address of the interrupt 
priority controlling routine 
(PRIOR) . 
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System Entry Points (cont'd) 



NAME VALUE 



.SHLT 


.NREL 




address 


.STAK 


. ZREL 




address 


START 


.NREL 




address 


.SYS. 


* User 




1 - System 


.TERM 


.NREL 




address 


.TTIO 


.NREL 




address 


.TTY0 


.NREL 






.TTYI 


.NREL 




address 


.TTYO 


.NREL 




address 



PLACES 
USED 

RTOS 



Device 
Handlers 

RTIN 



RTOS 
RTIN 

RTOS 

Device 

Handlers 

RTOS 

Device 

Handlers 

RTOS 



RTOS 
.MTTY 



RTOS 
.MTTY 



DESCRIPTION 



Start of a user program to 
handle the case when too few 
tasks were defined (also SHALT 
«D 

Address of the I/O job stacker 
routine (IOSTK) 



Starting address of user TASKS, 
branched to after completion 
of initialization. 



RTOS operating mode switch. 

Address of a list of termina- 
tion characters used to ter- 
minate input. 

Next I/O routine for the tele- 
type interrupt handler. 



Address of teletype unit 
device unit control block, 

Address of general routine 
to pre-process all teletype 
input 

Address of general routine 
to pre-process all teletype 
output . 
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E.l DEMONSTRATION PROGRAM NO. 1 

This program demonstrates the usage of all eight meta- instructions 
of the Real Time Operating System. To do this, it creates a number 
of parallel tasks performing data input and output to the teletype, 
suspends execution of the program for ten seconds, and uses the 
break feature to allow the user to restart the program at any point 
during its execution cycle. It uses the real time clock and 
console teletype so it can be run on the minimum hardware configura- 
tion necessary for using RTOS. 

The new user of RTOS should have thoroughly read the RTOS Reference 
Manual previous to attempting to follow the logic of this example. 

Once the system is initialized, the user TASK priority is set to 
100 octal. A restart TASK is then initiated at a higher priority 
(10 octal) to await the user typing a control C character on the 
teletype. When this break character is input, a complete re- 
initialization of the system will be performed. 

The initial TASK then initiates a parallel TASK (TASK1) to request 
the user to enter a ten character name on the teletype. This TASK 
is at the same priority as the initial TASK and so does not begin 
execution until the initial TASK has been completed or in this case 
causes a system rescheduling after initiating the output of a message 
"RTOS TEST PROGRAM" via an .IOX meta- instruction. This TASK, after 
completely outputting the message, terminates itself by a .QUIT. 

The first function performed by TASK1 is to initiate a TASK (TASK2) 
at priority 140 (octal) to input up to ten characters from the tele- 
type. Because TASK1 is higher priority than TASK2, it is scheduled 
for execution after completion of the .FORK instruction and starts the 
output of a message to the operator to enter a name "ENTER NAME:- 
". TASK1 is now in a suspended state until the message is completed 
and TASK2 is put in the executing state. TASK1 after completely out- 
putting this message issues a .RCV meta- instruction on channel 2 to 
wait for completion of the data input function of TASK2. 
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After completing the input phase (ten characters entered or ter- 
minated by one of the ASCII terminator characters: carriage re- 
turn, line feed, escape, end of text, or rubout) , TASK2 transmits 
the contents of AC3 when it returned from the .IOX instruction to 
TASK1 via channel 2. To use the .XMIT instruction, the message must 
be moved into AC0. It then performs a .QUIT operation. 

TASK1 upon receiving the message over channel 2 is again put into 
the pending state. When activated, it checks the message sent from 
TASK2 and contained in AC3. If TASK2 input was terminated by a 
carriage return, TASK1 types "<LF> IS" and if not, it types "IS". 
TASK1 then initiates a parallel TASK (TASK0) at priority 100 (octal) 
to wait ten seconds before requesting another name from the user. 
After TASK0 is initiated, execution of TASK1 resumes and outputs the 
characters of the name entered by the user in the reverse order to 
which they were entered. After the output is complete, a .QUIT 
instruction is executed to terminate the TASK. 

Included in the following pages are a program flow chart, program 
listing, and a copy of the program output. 
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DEMONSTRATION PROGRAM NO. 1 



START 



.PTY 
<100> 










RSTRT 


.FORK 
<10> 




.BRK 
<3> 










TASK 




ERROR 








.WAIT 
<1000.> 




IORST 






TASK 1 


















TASK 2 




JMP INIT 

i 


-.FORK 
<0> 




= FORK 
<140> 




ZERO TNPUT 
BUFFER 


























PRINT "RTOS 
TEST PROGRAM" 




PRINT 
"ENTER NAME:-" 




READ 10 
CHARS FROM TTC 






















.QUIT 




,RCV 

<2> 




.XMIT 
<2> 





YES 



PRINT 
"<LF> IS" 




.QUIT 



PRINT 
"IS" 



.FORK 
<100> 




TASK 



J 



PRINT INPUT 
DATA REVERSED 



.QUIT 



J REAL TIME OPERATING SYSTEM 
; utmuiNb i kh'I 10 iv PRGGRAi'-i n 1 

. T1TL OEM 01 

. ENT START 

. EX TiNi . I OX, . PTY, .QUI T, . LRX 
. EX 'IN . R C V* . X [-1 IT , . A I T , . EG RK 
.EX IN I'.Vl'i 



00000* 177777 
00001 '000100 

OO0U2* 177777 
00003' OOOGly 
00004*000017 * 

00005' 000002 ' 
00006 ' 00OOO0 
00007 '000026' 

00010' 177777 
0001 1 '000000 
U0012' 1O0000 
00013' 000000= 
0001 4*000100 



; Ilvl TIALl^ATIUiVi 


TA SK 


. ;^ R EL 




START: .PlY 

100 




. FORK 

10 

RSTRT 




. F U RK 



TASKl 





. I ox 


OUTP 
MESS1*2 

100 



i SET INITIAL PRIORITY 
;lu 100(3) 

; CREATE RESTART TASK 
; PRIORITY 10(8) 



; R E A T E PAR AL L EL T A SK 

;AT SAME PRIORITY (100(8)) 



5UUTPUT MESSAGE TO TTY 

} M <1 5>< 12>< 1£>KT0S TEST" 

; TERMINATED BY NULL ChARACTER 



00016* 177777 



.0 01 T 



', T E Rr-1 I N A T E I N IT I AL TA SK 
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t 1 1 



DEM01 



J SYSTEM KESTART TASK 



00017' mm 
00020'000003 



RSTRT: 



• BRK 
3 



i BREAK ChARACTER IS CONTROL C 
ill WILL RESTART SYSTEM 



; ERROR hANDLING ROUTINE (RESTART) 





rr •"*■■ ^ -—■ " > 


IORST 


00022*002401 




JMP §.+ 


00023' mm 




INIT 




J DELAY 


TASK (WA 


a cacao yi • 1 tttii 

WVUU- 3 XFffft 


TA Cl/ ra. 


l.i ATT 

• wn X 1 


00025'001750 




1000. 




J MESSAGE OUTPUT- 


00026" 000005' 


TASK!: 


.FORK 


00027 '000 140 




1 40 


00030'0001 1 4' 




TASK 2 


00031 '000010' 




. I OX 


00032*000000 







00033' 100000 




OUTP 


00034'000026= 




MESS2+2 


00035'000100 




100 


00036'000021 ' 




ERROR 



} t-RROK ROUlINk. 
JRE-INITALIZE SYSTEM 



TEN SECONDS BEFORE REDOING) 



TASK 



BEFORE RESTARTING TASK1 



; CREATE PARALLEL TASK 
>AT PRIORITY 140(8) 



OUTPUT MESSAGE 

"<1 5>< 12> ENTER NAME 

TO PROMPT OPERATOR 



00037* 177777 
00040*000002 

00041 '624412 
00042' 166404 
00043'00041 1 

00044'000031 ' 
00045'000000 
00046' 100000 
00047*000050= 
00050*000100 
00051 '000021 ' 

00052'000410 

00053*000015 CR: 



.RCV 



00054'000044* 
00055'000000 
00056' 100000 
00057'000051= 
00060'000100 
00061 '000021 ' 



NOLF: 



LDA 1,CR 


SUB 3, Ij. S2R 


JMP NOLF 


. I OX 





OUTP 


MESS3*2 


100 


ERROR 


JMP REVER 



15 

. I OX 



OUTP 

MESS3*2+1 

100 

ERROR 



J WAIT FOR MESSAGE FROM TASK 2 
i TRANSMITTED IN AC3 

J TEST IF INPUT TERMINATED 
; BY CARRIAGE RETURN 
J NO 

J PRINT "<LF> IS " 



; CARRIAGE RETURN ChARACTER 
;PRINT " IS " 
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r t t 



DEM 01 



00062*020055- 
000 63*0 40020 
0006 4' 40021 



REVER: LDA 0, LAST 
STA 0* I NCI 
STA W* INC2 



SETUP TO REVERSE BUFFERS 



00065' 102 400 
00066' 024056- 
000 67*0 42020 
00070' 125404 
00071 '0007 7 6 

00072' 020054- 
00073*040030 
0007 4*024056- 
0007 5' 022030 
00076* 101004 
00077'042021 
00100' 12 540 4 
00101 * 00137 7 4 



00 102 '000026' 

00103' 000100 
0010 4*00002 4' 



SUB 


0.. 


LDA 


1* TEN 


STA 


Q, 3 1 NCI 


INC 


1 , 1 , S2 R 


JMP 


.-2 


LDA 


0* FIRST 


STA 


i), DEC1 


L E'A 


1 , T EN 


LDA 


0, SDEC1 


n v 


0* 0* Sit R 


STA 


0* SINC2 


INC 


1 j LSEK 


J MP 


. - 4 


. FORK 


100 




"l/i Sf- 


< 



5FER0 THE. OUTPUT BUFr ER 



; REVERSE ThE INPUT BUFFER 
; PUTTING ThE RESULTS 
i IN ThE OUTPUT BUFFER 



J C i< EM T £ PA R AL L EL T A SK 
i TO START CYCLE AGAIN 
J In TEN SECONDS 



00105' 000O54' 

00106'000000 

00107 ' 12000k) 
001 10*000041- 
001 1 1 * 000 100 
001 12'000021 * 



. I OX 

i 

OUTF+0ORD 
OUTPUT 
100 
ERROR 



5 OUTPUT ThE ENTERED NAME 
;lN REVERSE ORDER 



001 13*00001 6' 



iun 



J TERMINATE TASK1 



; DATA INf-UT TASK 



001 1 4' 


'020054- 


TASK 2: 


LDA 


0, FIRST 


001 1 5' 


'0 400 30 




STA. 


®, DEC1 


001 16' 


' 102400 




SUB 


0, 


001 17 ! 


' 0240 56- 




L Da 


1* TEN 


00120' 


•04203O 




STA 


0, L'DECl 


00121 ' 


' 125404 




INC 


1 , 1 > 55 R 


00122' 


'000776 




JMP 


.-2 



iEE.RO INPUT BUFFER 



00123*000105* 
00124'00000U 
00125* 022000 
00126'000027- 

00127 '000012 
00130'000021 ' 



. I OX 

i 

EVEN+l"ORD 
INPUT 
10. 
ERROR 



i INPUT UP TO TEN 
CHARACTERS FROM ThE 1 TY 
J EVEN PARITY* WORD FORMAT 



00131 ' 1 61000 
00132' 177777 
00133'000002 



MOV 3* 

.XNIT 

2 



;P.C0= RETURN AC3 VALUE 

5 TRANSMIT MESSAGE TO TASK1 



O0134'0001 13' 



.QUIT 



; TERMINATE TASK 2 
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t 1 1 



DEM01 



; MESSAGE AND DATA STORAGE AREA OF PROGRAM 
.ZREL 



■m F c: c; i • 



00000-005015 
00001-051012 
00002-047 524 
00003-020123 
00004-042 524 
00005-052123 
00006-050040 
00007-047 522 






00011- 

00012- 

00013- 
0001 4- 
00015- 
00016- 
00017- 
00020- 
00021- 
00022- 
00023- 

00024- 
00025- 
00026- 



46 501 
000000 

00 5015 
047105 
42 52 4 
020122 
040516 
04251 5 
035040 
020055 
000000 

020012 
05151 1 

000040 



MESS2: .TXT !< 1 5>< 1 2> ENTER NAME 



MESS3: .TXT !<12> IS ! 



000012 
000012 
00053-000000 
00054-000041- 
00055-000040- 
00056-177766 

002000 
100000 
020000 
000020 
000021 
000030 

000021 ' 



INPUT: 
OUTPUT 

FIRST: 

LAST: 

TEN: 



10. 
10. 



• BLK 

.BLK 



OUTPUT 

OUTPUT- 1 

-10. 



EVEN = 
OUTP= 
WORD= 
INC1 = 
INC2= 
DEC1 = 



2000 
100000 
20000 
20 
21 
30 



i INPUT BUFFER 
i OUTPUT BUFFER 

i INPUT BUFFER ADDR.+l 

iOUTPUT BUFFER ADDR.-l 

I BUFFER LENGTH. (NEGATIVE) 

i EVEN PARITY 

; OUTPUT OPERATION 

i WORD FORMAT 

i AUTO- I NCREM EN TI NG 

REGISTERS 

J AUTO- DECREMENTING REG. 



END ERROR 
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o u 

0LG1 

ERROR 

EVEN 

FIRST 

I N G 1 

I NC2 

I N IT 

INPUT 

LAST 

Ri ESS1 

s >iESS2 

>-iESS3 

ttOLF 

OUTF 

OUTPU 

h'EVER 

l\ ii I i > i 

START 

TASKt) 
TASK 1 
TASK 2 

1 ER 
WORD 

• Dl.K 

. FORK 

• I OX 
. P TY 

. i,-UIT 
. RCV 
. WAIT 

. A.il'l 



00 O0 53 ' 

0Q0O30 

000021 ' 

002000 

0000 54- 

00O020 

000021 

000023 *X 

000027- 

000055- 

000000- 

000013" 

000024- 
000054' 
1 R: >tjtJO 
000041- 
000062' 

000017 ' 

000000' 
000024' 
000026' 
iuol 1 4' 

300056- 

02O003 

0u0'~17'X 

000102'X 

01",. I'A \ o *"► • V 

000000' X 
000 1 34" X 
000037 'X 

000004'X 



1>BU 



13J 
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DEMONSTRATION PROGRAM NO. 1 
Operation 



RTOS TEST PROGRAM 

ENTER NAME :- RIOS TEST IS TSET SO 'if: 

ENTER NAME :- DEMO NO. MS f .ON OMED 

DTAC T'.T-<-1 ;-..■-.,•,...:-..- 

"IU-) ICO I r/iUuKhh 

ENTER NAME :- DEi-iQ NO, 

KTOS TEST PROGRAM 

ENTER NAME :- DEMO NO It: IS 21 ON Oi-jEu 

ENTER NAME :- 

ETOS TEST PROGRAM 
ENTER NAME :- IS 

RTOS TEST PROGRAM 

ENTER NAME :- RACRWAERS IS SLRA'.vKUAn 
ENTER NAME :- FGEMAERS IS SbhAOROF 
ENTER NA 

RTOS TEST PROGRAM 
ENTER N 

RTOS TEST PR 

RTOS TEST PROGRAM 

EnVeR NAME :- AoCDEFGhU IS JIhGFElXJLA 

t-NTER NAME :- ABCREFGHJ.F IS JI 

RTOS TEST PROGRAM 
ENTER NAME :- IS 
ENTER NAME :- EVE IS EVE 
ENTER NAME :- AbCDEFGh 
IS hGFEDCbA 

rtos test program 
enter name :- 
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